The Very Best of Atari Inside/The Very Best of Atari Inside 1.iso/mint/mintman/mint.doc

Text File | 1991-11-02 | 29KB | 577 lines

MiNT is Not TOS: A Multitasking Operating System Extension for the Atari ST

Copyright 1990,1991 Eric R. Smith. All rights reserved. See the file COPYING
for conditions of redistribution.

WARNING: This program does some very low level things to your computer.
MiNT works well on my machine, and I trust my data to it. But
then, I make regular backups, so even if a horrible bug in MiNT that
I haven't found yet trashes my hard drive, I won't lose much. You'll
have to decide for yourself about trusting your data to MiNT. I would
certainly recommend regular backups in any event.

MiNT COMES WITH ABSOLUTELY NO WARRANTY, NOR WILL I BE LIABLE FOR ANY
DAMAGES INCURRED FROM THE USE OF IT. USE ENTIRELY AT YOUR OWN RISK!!!

Introduction

MiNT is an extension of (and eventually, I hope, a replacement for) TOS.
It provides extra services such as multitasking and pipes. If you don't
know what those terms mean, MiNT is probably not for you -- at this stage,
MiNT is still very incomplete and should be regarded as "experimental".

MiNT will run a great number of ("most", I hope) TOS programs, including
GEM. As the name says, though, MiNT is not TOS, so it can't be expected to
run all TOS programs, or even all well-behaved TOS programs (although I hope
that it will run "almost all" of the latter!). There are two classes of
incompatibilities with TOS: bugs and features. Bugs are undoubtedly
present; if you find any please report them to me. There are also some
features of MiNT that may cause incompatibilites. Most of these are listed
in the accompanying "features" file.

MiNT tries to emulate TOS 1.4 very closely. If you have TOS 1.0 or 1.2,
you may think you can use MiNT instead of buying TOS 1.4. This isn't really
a very good idea, because MiNT calls TOS, and so having the newer version
of TOS will really speed things up. Besides, the GEM that comes with TOS 1.4
is a lot better than the old GEM.


Using MiNT

MiNT can be started from an AUTO folder, by setting it as a BOOT program
on the desktop (TOS 1.4 or higher only) or by running it. I prefer the AUTO
folder way myself.

If you put it in an AUTO folder, it should be the last thing in the folder
(since any later programs in the folder will run only after MiNT is finished,
and MiNT should never finish). MiNT will try to run a program called
"init.prg" in the current directory  (which is the root directory if MiNT
was started from an AUTO folder). If this program isn't found, MiNT will
boot up GEM. You can change the name of the initial program to run
via the "mint.cnf" file (see below).

Once MiNT is running, the computer should behave just as it does under TOS,
except that some new drives (U, Q, V, and X) will be available, background
processes can be started, and programs can use the new features of MiNT.

MiNT can be asked to provide a trace of the currently executing programs.
Hitting CTRL-ALT-F1 increases the debugging level; hitting CTRL-ALT-F2
decreases it, and hitting CTRL-ALT-F3 changes where the debugging output
goes; pressing it once changes it from the screen to the printer, pressing
it again changes it to the RS232 port, pressing a third time sends debugging
output to the MIDI port. Pressing CTRL-ALT-F4 resets output to the screen.
This feature was designed to aid in debugging MiNT itself, but can also be
useful in finding problems with user programs. Debugging level 0 (the normal)
prints messages only when something goes seriously wrong inside of MiNT itself.
Debugging level 1 prints a message when any system call fails. Debugging level
2 provides a (sickeningly) exhaustive trace of what's going on in the system.

CTRL-ALT-F5 shows what memory is being used in the system
CTRL-ALT-F6 prints a list of all processes in the system
CTRL-ALT-DEL provides a (warm) boot, as in TOS >= 1.4, and
CTRL-ALT-SHIFT-DEL provides a cold boot.

Some other keys are recognized by MiNT if the process is doing I/O in
"cooked" mode:
^C (CTRL-C): interrupt running program with signal SIGINT. This (usually)
    will kill the process, unless it has made arrangements to catch it.
    Note that ^C takes effect immediately under MiNT, whereas under TOS
    it only takes effect when the process reads or writes.
^\: send a QUIT signal to a process; usually the same end result as ^C, but
    it is guaranteed to kill a TOS program (only MiNT specific programs
    know how to catch it). Use with caution.
^Z: suspend the current process

These keys do *not* have any effect on processes operating in "raw" mode,
such as editors. However, you can force these to work even on such programs
by holding down the ALT key as well, i.e. CTRL-ALT-Z will always suspend
the process. You should use caution when doing this, since some programs
will function incorrectly and/or lose data if interrupted when they
aren't expecting it.


The MiNT Configuration File

If MiNT finds a file called "mint.cnf" in the root directory of
the disk, it will read some configuration information from it. This
file is an ordinary ASCII text file; it can be created with any editor
that will produce plain ASCII files (if you're using a fancy word
processor, make sure you save the file as "plain ASCII text" or
"unformatted text" or whatever).

The commands in mint.cnf are placed one per line, and may be of the following
forms:

INIT=d:\foo\bar.prg
    This specifies the drive and full path name to the program you
    want MiNT to run at boot up time. The default is ".\init.prg".

cd d:\foo
    Change the current drive and directory. This isn't terribly
    useful, unless your initial program (see above) expects to run
    with some particular directory as the current one.

sln d:\foo\bar u:\baz
    Create a symbolic link called "u:\baz" for the file (or directory)
    d:\foo\bar. Only drive u: supports symbolic links, so the second
    name *must* be on drive u:; the first name can be anything.
    A symbolic link is just an alias or nickname for a file; if the
    sample line is included in your mint.cnf file, then references
    to u:\baz are automatically translated by the kernel so that
    they "really" refer to d:\foo\bar. If d:\foo\bar is actually
    a subdirectory, with the file "frob.txt" in it, then that
    file can be accessed either through the name "d:\foo\bar\frob.txt"
    or "u:\baz\frob.txt".

    Symbolic links are often used to tell programs where to look for
    files; in this respect they're somewhat like environment variables.
    Some "standard" links are:
        u:\bin        directory to find programs in
        u:\etc        directory to find certain general
                configuration files (e.g. passwd and termcap)
        u:\local    directory to find node-specific files in
                (for networked systems)
        u:\lib        directory to find C libraries in
        u:\include    directory to find C header files in
    You can use whatever of these are convenient, or add some others
    of your own.

ren d:\nm1 d:\nm2
    Rename a file or directory. This is useful mainly on the pseudo-drive
    v:, which refers to devices. For example, the RS232 port on the ST
    is called "v:\modem1". Earlier versions of MiNT called this
    "v:\rs232", so if your programs care about this you might want
    to put "ren v:\modem1 v:\rs232" to maintain compatibility.
    Similarly, if your software has been ported from Unix and expects
    terminals to be called "tty*", then you might want to put
    "ren v:\modem1 v:\tty1" instead.


Pseudo Drives

MiNT provides some fake "disk drives"; if the contents of these drives
are listed, various "files" are shown. These "files" are not necessarily
real files, but may represent other objects such as executing programs or
regions of memory.

The following drives are available:

Drive Q:: contains files which are FIFO queues (e.g. pipes). All files
created on drive Q are temporary; when the last program using a FIFO
closes it, it is erased. Normally, drive Q will be empty, but it will
have items on it when you're running a window manager, print spooler,
or similar program that uses FIFOs or pseudo-ttys for communication.

Drive V:: contains files which correspond to the BIOS devices; this allows
you to access these devices from within programs. For example, saving an
ASCII text file to "V:\PRN" should cause it to be printed on your printer.
Of course, this will work *only* with ASCII data, so don't expect to get
anything meaningful printed if you try to save your spreadsheet to "V:\PRN"!
The following devices are available:
   CENTR: the centronics printer port
   RS232: the RS232 serial port
   MDI: midi port
   KBD: intelligent keyboard controller
   PRN: printer device (not necessarily the real printer if redirected)
   AUX: auxiliary terminal (usually, but not always, the rs232 port)
   CON: current control terminal (NOT necessarily the keyboard/screen!)
   TTY: same as above
   STDIN: current file handle 0 (standard input)
   STDOUT: current file handle 1 (standard output)
   STDERR: current file handle 2 (standard error)
   CONSOLE: (physical console) the keyboard/screen
   MOUSE: the mouse
   NULL: a null device (like Unix's /dev/null)

The "STD*" file handles are useful for providing I/O redirection to programs
that normally require file names on the command line; for example, if you
want to run such a program in a pipeline.

Drive X:: listing this drive gives information about currently executing
processes, such as whether they're running, ready, or waiting, their process
i.d. numbers, and the amount of memory they've taken. Deleting one of the
"files" kills the corresponding process. (Killing MiNT is impossible;
killing GEM is a very bad idea). The "files" will have names like "INIT.001";
this means that the process name is "INIT" (presumably because it was started
from a file like "INIT.PRG"), and its process i.d. is 1. You can rename
processes just as if they were files, except that any extension you give is
always replaced with the process i.d. (e.g. if you rename INIT.001 to FOO.BAR,
it will really become FOO.001). The size of a process is the amount of memory
that is allocated to it. Its date/time stamp reflects how much processor
time it has consumed; for example, a process that has consumed 27 hours,
13 minutes, and 6 seconds of computer time will have a date of Jan.2, 1980
and a time of 03:13:06 (because of the way GEMDOS stores dates, the "0"
point is midnight, Jan. 1, 1980). A process' current state is reflected
by its attribute bits; most of these are not visible from the desktop, alas,
but here are the combinations and their meanings:
    attribute      process state
      0x00        currently running
      0x01        ready to run
      0x20        waiting for an event (e.g. for a child to finish)
      0x21        waiting for I/O
      0x22        zombie (exited, but parent doesn't know yet)
      0x02        terminated and resident
      0x24        stopped by a signal
Deleting a "file" on drive X: will send a SIGTERM signal to the corresponding
process, which will usually result in that process being terminated. It
is not possible to delete processes which are terminated and resident,
or zombie processes.

Drive U:: a "unified" file system; all the other drives are visible
on this device. For example, the file C:\FOO can also be referred to
as U:\DRVC\FOO, and X:\INIT.001 is the same as U:\PROC\INIT.001. The
subdirectories "PIPE", "DEV", and "PROC" respectively on drive U:
refer to drives Q:, V:, and X:. The use of the directories on drive U:
instead of these drives is preferred; future versions of MiNT may change
or do away with drives Q:, V:, and X:, but the drive U: subdirectories will
always work.

Note that the TOS 1.0 desktop won't recognize drives above P. Other versions
of TOS will, though, so you can use the Install Drive menu selection to
install the pseudo drives so that the desktop can recognize them.


File Handles and Devices

File handle -1 refers to the current control terminal, NOT necessarily
the console (this is where it points by default). BIOS handle 2 also
refers to the control terminal, so that e.g. Bconout(2, c) outputs
a character to the control terminal. Thus,
    Fforce(-1, Fopen("V:\RS232", 3));
    r = Bconin(2);
reads a character from the RS232 port under MiNT. This is done so that
programs that use the BIOS for I/O will be able to run in windows or
over the modem. Similarly, the DOS device CON: refers to the current
control terminal, so Fopen("CON:", 3) is normally equivalent to Fdup(-1).
To access the physical console, use device V:\CONSOLE.

In a similar fashion, file handle -2 and bios device 1 (DOS device AUX:)
may be redirected away from the RS232 port (device V:\RS232), and
file handle -3 and bios device 0 (DOS device PRN:) may be directed away
from the Centronics printer port (device V:\CENTR). Since both the DOS
handles and BIOS device numbers are redirected, any program at all will
obey the redirection unless it accesses the hardware directly (or unless
it was written for MiNT and specifically uses the new device names
like V:\CENTR; this should be done only if *absolutely* necessary!).

File handles -4 and -5 are new with MiNT, and refer to the MIDI input
and output devices respectively. Redirecting these handles will affect
BIOS operations on bios device 4 (the MIDI port).


Background Processes

(Note that the programs bg.ttp and pipe.ttp, along with some other
sample MiNT utilities, are found in a separate file called
"mntutl.zoo").

Programs may be started in the background. A sample program ("bg.ttp")
is provided that will do this for you. It works best from a shell;
for example, to make foo.ttp in the background from gulam, type:
    cd \foo\src
    bg.ttp -o make.out make foo.ttp
The "-o make.out" tells "bg" to redirect the command's standard tty,
output, and error output (handles -1, 1, and 2) to "make.out".
You might also want to redirect the standard input from an empty
file, or from a file that will never have input waiting (like V:\NUL)
so that "make" won't try to read anything from your console.

Shells designed to work with MiNT (for example, the "init.prg" that is
provided) may use the Unix "&" notation for running processes in the
background; with this notation, the job above would be:
    cd \foo\src
    make foo.ttp >make.out &
(here the ">make.out" is the notation for redirecting the standard output
of a process). Note that the sample shell does not provide a way of
redirecting the standard error output; however, it does provide job
control (see below), and processes that try to write on the terminal
will be stopped automatically.

Only one GEM program can be active ("ready") at a time. This essentially
means that GEM programs cannot be run in the background. It wouldn't
make much sense, anyways, since GEM programs take over the whole screen.


Pipes

Pipes are special files that are used to communicate between processes. The
data in a pipe is always in memory, so using a pipe instead of a temporary
file is usually faster; it also doesn't consume disk space. Only 2048 bytes
can be held in a pipe at once; when a process tries to write more data,
it is suspended until another process reads some data, thus "emptying"
the pipe. If there are no more readers, a process writing on a pipe is
terminated.

A simple "pipe" program is provided to run two programs concurrently,
passing data between them in a pipe. The syntax is
    pipe.ttp cmd1 cmd2
which is equivalent to the Unix "cmd1 | cmd2". Note that if cmd1 or cmd2
contain arguments, then you must run the "pipe" program from a shell that
supports the Atari standard extended argument convention, and that you
must enclose the commands in quotes, e.g. in gulam:
    set env_style mw    # extended arguments
    pipe 'ls.ttp -l foo' 'fgrep.ttp myfile'
does the same as the Unix command
    ls -l foo | fgrep myfile
or using a temporary file
    ls -l foo >junk; fgrep myfile <junk; rm junk

Shells designed to work explicitly with MiNT will probably not need the
external "pipe" command, and instead will use the Unix notation for
pipelines. (The sample shell that comes with MiNT as init.prg does
this). This second method is preferable, as it provides a way of
joining more than two programs in a pipeline.


Job Control

MiNT currently (as of version 0.6) supports job control. The ^Z
(control-Z) key can be used to suspend a process. The process can
be restarted again if it is sent the appropriate signal. A sample
program (fg.ttp) is provided that will do this; the syntax is
    fg.ttp process-name
where "process-name" is either the process id of the process, or its
name as displayed in the drive X: listing (e.g. gem.003). If the process
was not stopped, an error will occur.
There is also a "delayed" suspend key, ^Y, that takes effect only when
a process attempts to read it.

Some programs written for TOS put the terminal in "raw" mode, where no
control characters are interpreted. You can use CTRL-ALT-Z to achieve
the effect of ^Z for such programs. However, this feature should be used
with caution -- it's possible that the TOS program had a good reason
for not wanting to be interrupted!

More sophisticated job control facilites can be provided by shells that
are specifically written with MiNT in mind. The sample "init.prg"
demonstrates this. Jobs run in the background from such shells are auto-
matically stopped when they attempt to read from the terminal or write to it.
Thus, you can run a long compile in the background, and if an error
occurs and the compiler attempts to write on the screen, it will be stopped.


Programming with MiNT

A file (mintbind.h) is provided that gives a C interface to the new
MiNT system calls. Users of other programming languages will have to write
the interfaces themselves; it should be relatively straightforward, as long
as your compiler provides a way to call GEMDOS directly.

Testing for the presence of MiNT:

There are several ways to check to see if MiNT is active. Probably the best
way is to check the cookie jar; MiNT installs a cookie of
0x4d694e54 (in ASCII, 'MiNT'), with a value consisting of the major/
minor version numbers in the high/low bytes of the low word. Thus, MiNT
version 1.2 will have a cookie value of 0x00000102L. (This isn't
the place to explain the cookie jar, but basically it's a list of
(cookie, value) pairs of longwords, terminated by cookie 0; a pointer
to the jar is found at 0x5a0. MiNT always installs a cookie jar; versions
of TOS prior to 1.6 don't always, in which case 0x5a0 will contain 0).

A "quick and dirty" way to see if MiNT is active is to make a system
call that only exists under MiNT (preferably one with no side effects!).
Pgetpid() or Syield() are good choices. If MiNT is not active, these
calls will fail, returning -32 (invalid function). This method has the
disadvantage that future versions of TOS, or other multitasking programs,
may use the same trap numbers as MiNT, but have different meanings.
For this reason, the "cookie jar" method is preferred.

Interprocess Communication:

MiNT provides 4 forms of interprocess communication (IPC): signals, fifos,
shared memory, and message passing.

Signals:

Signals are a way of notifying a process of an event. The Pkill(pid, sig)
system call is used to send signal number "sig" to the process with process
id "pid". It is called "Pkill" because the default action of most signals is
to terminate the process. If a process wishes to catch a signal and do
processing, it can use the Psignal(sig, func) system call to arrange to have
function "func" called when signal "sig" is received. If func is 0, then
the default action is restored. If func is 1, then the signal will be ignored.

Processes can temporarily block receipt of signals via the Psigblock() and
Psigsetmask() system calls.

See the file "signal.doc" in the MiNT Programmer's Guide for a more complete
explanation of signals.

Fifos:

Fifos are "first in first out" message queues. Pipes are a special kind of
(unidirectional) fifo. Fifos are represented by files in the subdirectory
"PIPE" on drive "U:". They are created with the Fcreate(name, flags)
system call. "name" will be the name under which the fifo is known
(maximum 13 characters); "flags" is explained below. The returned file handle
is treated just like an ordinary file, and may be written to and read from
(unless the fifo is unidirectional, in which case it may only be written to).
The program that creates the fifo is normally called the "server". Other
programs ("clients") may use the Fopen(name, mode) system call to open the
other end of the fifo and read the data that the server writes, or write data
for the server to read. When the last program (either client or server) using
a fifo closes it, the fifo is deleted automatically. Note that one program can
be both client and server, if it creates a fifo with Fcreate and then opens it
again with Fopen. Also, children of the server can inherit the Fcreate'd file
handle and thus have access to the "server" side of the fifo.

The bits in the "flags" argument to Fcreate have the following meanings:
0x01: make fifo unidirectional (server can write, clients can read)
0x02: cause reads to return EOF if no other processes are writing, and writes
      to raise the SIGPIPE signal if no other processes are reading. The
      default action (if this flag is not given) is to block waiting for
      reads and writes
0x04: make the fifo a pseudo-tty; to client processes, the fifo will act
      just like a terminal with the server "typing" the characters; for
      example, if the server writes a ^C, SIGINT will be sent to clients

Attempting to Fcreate() a fifo with the same name as an already existing
one will result in an access error (i.e. the Fcreate will fail).

Pipes may be created through the Fpipe() system call as well as through
the Fcreate/Fopen pair; the former method is easier, since the kernel
takes care of name conflicts, etc.

Fifos may be locked by processes via the Fcntl system call, as follows:

struct flock {
    short l_type;        /* type of lock */
#define F_RDLCK        0
#define F_WRLCK        1
#define F_UNLCK        3
    short l_whence;        /* what is the lock relative to? */
        /* 0 == start of file, 1 == current pos. in file, 2 == EOF */
    long l_start;        /* start of locked region */
    long l_len;        /* 0 for rest of file */
    short l_pid;        /* set by F_GETLK */
};

Fcntl(fd, &lock, F_SETLK): set a lock as specified by the lock structure.
The current version of MiNT only understands locks on the whole FIFO,
so lock.l_start and lock.l_len should both be 0. If lock.l_type is F_UNLCK,
then the lock is released. Otherwise, the file whole file is locked
(future versions of MiNT may distinguish between read and write locks,
but for now all locks are treated as write locks (F_WRLCK) and block both
reads and writes). If another process has locked the fifo, returns -36
(access denied). If a process holding a lock terminates, the fifo is
automatically unlocked.

Fcntl(fd, &lock, F_GETLK): if a lock exists on the fifo, set lock to
indicate what kind of lock it is; otherwise, set lock.l_type to F_UNLCK.

Locks are only "advisory"; that is, programs may ignore locks if they
choose to do so. However, they are a good way to insure that two clients'
data are not mixed together in a fifo.

See the sample LPR and LPD utilites for a demonstration of how to use fifos.

Shared memory:

Children created with the Pexec(4,...) or with Pexec(104,...) share all of
their parent's memory, as do children created with the Pvfork() system call.
Hence, they may communicate with their parent (or with each other) via
global variables.

Rendezvous:

The Pmsg() system call provides a simple message based form of IPC. See
the manual page for Pmsg in the MiNT Programmer's Guide for further details.


MiNT extensions to GEMDOS calls:

Fsfirst/Fsnext:
    MiNT domain processes (see the Pdomain()) system call below) get
lower case filenames from Fsfirst/Fsnext on a TOS filesystem. This is
because most programs end up converting them to lowercase anyways, to
be more Unix-like. *Please* don't do this translation yourself, let
MiNT handle it -- some filesystems (e.g. the minix one) are case
sensitive! If you really, truly, prefer uppercase filenames, run in
the TOS domain.

Pexec(100, name, cmdline, environment):
    Similar to Pexec(0, ...), except the calling program does not wait for
the child to finish. Returns a negative error code, or the (positive)
process I.D. of the child.

Pexec(104, name, basepage, 0L):
    Similar to Pexec(4, ...); starts executing a basepage previously
set up by Pexec mode 3, 5, or 7. The caller does not wait for
the child to finish. Returns a negative error code, or the process I.D.
of the child. Note that the child's environment and basepage are
owned by both the child and the parent. "name" is a pointer to a string
to be used to supply a name for the new process; if it is NULL, then
the parent's name is used.

Pexec(106, name, basepage, 0L):
    Similar to Pexec(104,...) except that the child's environment and
basepage are *not* owned by the parent.

Pexec(200, name, cmdline, environment):
    As with Pexec(0,...) and Pexec(100,...) this runs a program. However,
with this variant the caller is completely replaced with the executing
program. The process retains its process i.d. and most other attributes,
but all of its memory is freed and a new address space is set up for it
containing the code from the indicated program. Whereas Pexec(0,...)
is like a subroutine call, Pexec(200,...) is like a "goto". It returns
only if an error occurs.


New MiNT calls:

See the manual pages in the MiNT Programmer's Guide for descriptions of
these calls. (The MiNT Programmer's Guide is available separately in
the file mintdoc.zoo).

word Syield():                    [ GEMDOS 0xff ]
word Fpipe( word *ptr ):            [ GEMDOS 0x100 ]
word Fcntl( word f, long arg, word cmd):    [ GEMDOS 0x104 ]
long Finstat( word f ):                [ GEMDOS 0x105 ]
long Foutstat( word f )                [ GEMDOS 0x106 ]
long Fgetchar(word f, word mode):        [ GEMDOS 0x107 ]
long Fputchar( word f, long c, word mode ):    [ GEMDOS 0x108 ]
long Pwait():                    [ GEMDOS 0x109 ]
word Pnice( word delta ):            [ GEMDOS 0x10a ]
word Pgetpid():                    [ GEMDOS 0x10b ]
word Pgetppid():                [ GEMDOS 0x10c ]
word Pgetpgrp():                [ GEMDOS 0x10d ]
word Psetpgrp(pid, newgrp):            [ GEMDOS 0x10e ]
word Pgetuid():                    [ GEMDOS 0x10f ]
word Psetuid( word id ):            [ GEMDOS 0x110 ]
word Pkill( word pid, word sig ):        [ GEMDOS 0x111 ]
long Psignal(word sig, long handler):        [ GEMDOS 0x112 ]
word Pvfork():                    [ GEMDOS 0x113 ]
word Pgetgid():                    [ GEMDOS 0x114 ]
word Psetgid(word id):                [ GEMDOS 0x115 ]
long Psigblock(long mask):            [ GEMDOS 0x116 ]
long Psigsetmask(long mask):            [ GEMDOS 0x117 ]
long Pusrval(long arg):                [ GEMDOS 0x118 ]
word Pdomain(word newdom):            [ GEMDOS 0x119 ]
void Psigreturn():                [ GEMDOS 0x11a ]
long Pfork():                    [ GEMDOS 0x11b ]
long Pwait3(word flag, long *rusage):        [ GEMDOS 0x11c ]
word Fselect(word timeout, long *rfds, long *wfds, long *xfds):
                        [ GEMDOS 0x11d ]
void Prusage( long r[8] ):            [ GEMDOS 0x11e ]
long Psetlimit(word lim, long value):        [ GEMDOS 0x11f ]
long Talarm( long secs ):            [ GEMDOS 0x120 ]
void Pause():                    [ GEMDOS 0x121 ]
long Sysconf( word n ):                [ GEMDOS 0x122 ]
long Psigpending()                [ GEMDOS 0x123 ]
long Dpathconf( char *name, word n ):        [ GEMDOS 0x124 ]
long Pmsg( word mode, long mbox, void *msg ):    [ GEMDOS 0x125 ]
long Fmidipipe( word pid, word in, word out ):    [ GEMDOS 0x126 ]
word Prenice( word pid, word delta ):        [ GEMDOS 0x127 ]
long Dopendir( char *name, word flag ):        [ GEMDOS 0x128 ]
long Dreaddir( word buflen, long dir, char *buf):[GEMDOS 0x129 ]
long Drewinddir( long dir ):            [ GEMDOS 0x12a ]
long Dclosedir( long dir ):            [ GEMDOS 0x12b ]
long Fxattr( word flag, char *name, void *buf ):[ GEMDOS 0x12c ]
long Flink( char *oldname, char *newname ):    [ GEMDOS 0x12d ]
long Fsymlink( char *oldname, char *newname ):    [ GEMDOS 0x12e ]
long Freadlink( word siz, char *buf, char *name):[GEMDOS 0x12f ]
long Dcntl( word cmd, char *name, long arg ):    [ GEMDOS 0x130 ]
long Fchown( char *name, word uid, word gid):    [ GEMDOS 0x131 ]
long Fchmod( char *name, word mode ):        [ GEMDOS 0x132 ]